-
Notifications
You must be signed in to change notification settings - Fork 6
unix_api: Add support for pthreads #288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Reorder the pthread_ functions to be in alphabetical order and add a doc comment to each function, following the existing style in the file.
| (attr == NULL) ? NULL : (pthread_condattr_t *)attr->_pthread_condattr_t); | ||
| *err = errno; | ||
| if (r == 0) { | ||
| cond->_pthread_cond_t = c; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a need to assert that cond has not been already initialized? Calling this function more than once against same cond will result in a memory leak, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, POSIX allows me to do that ;-)
I think that I capture the behavior required by the standard:
Attempting to initialise an already initialised condition variable results in undefined behaviour.
The function pthread_cond_destroy() destroys the given condition variable specified by cond; the object becomes, in effect, uninitialised. An implementation may cause pthread_cond_destroy() to set the object referenced by cond to an invalid value. A destroyed condition variable object can be re-initialised using pthread_cond_init(); the results of otherwise referencing the object after it has been destroyed are undefined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just meant that here(and in other methods below where we do calloc) the behavior will be well-defined in that aspect that it will create memory leaks.
But yeah, perhaps since it's posix "undefined behavior" territory, it might be not too terrible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would I tell if this is the first initialization or not? If the user uses malloc then the contents of the struct could be anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. I think I just wished that there would be no malloc/free in these methods. But I don't have a proposal on how to avoid them neither.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to add this file too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a delete.
Contribution guidelines:
dart format.Many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.
Note: The Dart team is trialing Gemini Code Assist. Don't take its comments as final Dart team feedback. Use the suggestions if they're helpful; otherwise, wait for a human reviewer.